1. Field of the Invention
The present invention relates to service management systems for use in communications networks and finds particular application in managing interactions between service features.
2. Description of the Related Art
Communications systems have become so large and complex that it has become difficult to predict the occurrence of possible interactions among their components. These interactions can result in the loss of intended functionality or cause unforeseen side-effects.
Modelling communication systems as dynamic constraint satisfaction problems is proposed as a means of performing avoidance, detection, and resolution of interactions. Methods for isolating the components responsible for the interaction are also discussed, as are ways of automatically generating inferences about them.
Communications systems have come a long way from providing simple telephone service. As the list of services provided has increased, so has the underlying complexity of the system. In the US, heterogeneity of service providers has compounded the problem by being based on inhomogeneous hardware and software. Even for a single service provider, the underlying networks and protocols can differ depending upon usage and types of services provided. The result is an incredibly large and complex system whose operation can be viewed as multiple levels of functional and logical abstraction. The management of such a system, such that consistent and high quality service is maintained, can become an overwhelming task.
A burr in the heel of consistent and high quality communications service is the feature interaction problem. Roughly speaking, features can be considered the services provided by the communications system. The potential problem that can arise, especially today with a large, increasing number of features available, is that different features, or multiple instances of the same feature, can cause unforeseen and unintended behaviour when operating together. An example of feature interaction is as follows:
Consider two common features provided to phone customers: call waiting (CW) and call forwarding on busy (CFB). Call waiting notifies the call recipient, who is already on the line, of an incoming call and allows the recipient to switch between the two calls, connecting with one, suspending the other. Call forwarding on busy, which engages when the recipient is already on the line, allows the recipient to have calls directed to another number. This features do not notify the call recipient. Both CW and CFB connect as normal calls when the recipient is not busy.
Separately, each feature can operate without any interaction. However, when both features are activated and the recipient is busy, interaction occurs, due to the fact that neither feature can be performed without sabotaging the operation of the other. Specifically, there are two different and conflicting actions to be performed when the call recipient is busy.
In xe2x80x9cFeature Interactions in Telecommunications Systemsxe2x80x9d, by E. Jane Cameron and Hugo Velthuijsen, published in the IEEE Communications Magazine Vol. 31, No. 3, pp 18-22, August 1993, three fundamental aspects of feature interaction problems are listed as avoidance, detection, and resolution.
The idea of avoidance of feature interaction is that relevant specifications are made clear enough that conflicts do not occur between features, whether in the design phase or at the point they are invoked. Avoidance can be extended to include those cases where it might have occurred, yet alternatives existed that allowed the features to be invoked without interaction.
Detection of interaction is useful in a number of stages. It can be used as a guide to designers at the point that they are creating new features and can also inform the system or the user of possible conflicts at the point a feature is added or invoked.
In order for the information to be useful, some sort of resolution is to be expected, such as all or some of the features involved in the conflict being modified or removed.
Published efforts have focused on providing examples of interactions and categorising the different ways they can occur, such as in xe2x80x9cA Feature Interaction Benchmark for IN and Beyondxe2x80x9d, by Cameron et al, IEEE Communications Magazine, Volume 31, No. 3, pp 64-69, 1993. In this publication, the authors attempt to classify various types of interaction based upon the basic cause of the interaction and posit that much of the problem is the failure to specify clearly a feature""s intended behaviour. In xe2x80x9cA Method for Detecting Service Interactionsxe2x80x9d, by Wakahara et al, IEEE Communications Magazine, Volume 31 No. 8, pp 32-37, the occurrence of feature interaction is attributed to a system""s lack of three types of knowledge, such as the implicit relationships among features, yet no systematic approach is given that could be automated to acquire this information. In xe2x80x9cSpecifying Telephone Systems in LOTOS and the Feature Interaction Problemxe2x80x9d, by Boumezbeur et al, IEEE Communications Magazine, Volume 31 No. 3, pp 38-45, August 1993, the use of LOTOS as a tool to model interaction is presented, where features"" processes and subprocesses can be represented and then symbolically executed to detect interaction. In xe2x80x9cA Practical Approach to Service Interactionxe2x80x9d, by Kuisch et al, IEEE Communications Magazine, Volume 31 No. 3, pp 24-31, 1993, interaction is viewed as overlapping or intersecting control intervals within a high-level framework known as the Basic Call State Model. xe2x80x9cService Interaction in an Object-Orientated Environmentxe2x80x9d, by Mierop et al, IEEE Communications Magazine, Volume 31 No. 8, pp 46-51, 1993, suggests an object-oriented approach in which feature interaction corresponds to the common use of a basic call object by two or more features. A more distributed approach is given in xe2x80x9cThe Negotiating Agents Approach to Runtime Feature Interaction Resolutionxe2x80x9d, by Griffeth et al, published in xe2x80x9cFeature Interactions in Telecommunications Systemsxe2x80x9d, at pp 217-234, edited by W Bouma and Hugo Velthuijsen, 1994, where the process of creating a situation free of interaction is viewed as a negotiating process between agents.
According to the present invention, there is provided a feature interaction management system, for use in the provision of communications services over a communications network by means of running call processing logic to control the network, wherein the feature interaction management system comprises:
(i) access to a feature representation store for storing constraint-based representations of service features;
(ii) a scenario simulator for providing simulations of call instance scenarios involving at least one communications service feature; and
(iii) a conflict detector for detecting conflicts between feature representations in a simulated call instance scenario,
wherein the conflict detector is adapted to detect conflicts by generating at least one constraint satisfaction problem and detecting inconsistencies in the constraint satisfaction problem, the problem comprising at least two constraint-based feature representations and a set of values for call instances, the set of values being provided by a simulated call instance scenario.
It will be understood that references to xe2x80x9ccallsxe2x80x9d and xe2x80x9ccall processingxe2x80x9d should be taken as references to connections generally in a communications network, for the provision of voice, data or other services, a call potentially being established for instance between equipment with no human presence.
Preferably, the system further comprises a resolution generator for receiving detected conflict information from the conflict detector and for generating at least a partial resolution to a detected conflict.
Constraint satisfaction is a known approach to problem solving but in quite different domains, such as scheduling.
A management system according to an embodiment of the present invention might be associated with a service creation environment and/or a service delivery system. Hence, conflict resolution could be applied when a new service is created and/or when a service is to be run.
If conflict resolution is to be applied when a new service is created, then, if a constraint-based representation of a feature used in the new service is associated with a detected conflict in a simulated call instance scenario, then this information needs to be made available to the service creation environment such that the service logic for the feature can be modified before installation. The constraint-based representation of that new feature will also be modified before storage in the feature representation store for use in future conflict detection. Where a resolution generator is provided, the modification to the service logic or the feature representation can be made in accordance with a resolution, or partial resolution, generated by the resolution generator.
When the conflict is detected between features for different users at run time for a service, clearly it will be important to alter aspects of at least one of the features in order to resolve the conflict. A particularly useful aspect that may be provided in preferred embodiments of the present invention is the provision of an alternative value, xe2x80x9calternative invokexe2x80x9d, being provided within constraint-based representations of features. In the associated service logic which is executed to provide the service feature to a user, this is translated to an alternative version of the service logic, so that the service feature actually operates in a different way. Thus the detection of the conflict provides a control mechanism which can be used effectively to xe2x80x9cswitch inxe2x80x9d different service logic on detection of the conflict.
The modification to the feature representation in response to detection of a conflict may then be simply instantiation for a variable in a constraint-based representation as the value xe2x80x9calternative invokexe2x80x9d. This provides a very simple means for selecting a feature in preference to another on detection of the conflict. The alternative invoke value may cause the selected feature to be invoked and to trigger a constraint so that the conflicting feature has a value instantiated as xe2x80x9cDEFERxe2x80x9d and consequently is not invoked.
Conflict between feature representations may arise because the feature representations make demands on common resources. If two features need to use the same resource in conflicting ways, then this will produce conflict. In preferred embodiments of the present invention, the conflict detector detects demands made on common network resources, by features, so as to cause conflict and the resolution generator is capable of generating a partial resolution in which some of those features which make demands on common network resources are deleted.
Where the management system is associated with service delivery at run time, preferably the resolution generator can generate a partial solution based on a minimum set of features to be deleted, or inhibited, with respect to services otherwise available to users. Preferably the resolution generator has the capability, for instance a default condition, in which the minimum set of features to be deleted or inhibited is distributed substantially evenly between affected users.
Additionally, or instead, the resolution generator may have access to priority data with respect to user services and may be capable of generating a resolution in which features are deleted or inhibited according to their relative priority. Said priority might be predetermined for instance by an affected user in respect of their own user or service profile, or it may be determined according to the priority of one user""s services over another user""s services. This might arise where one user pays a premium rate for guaranteed services while another user pays a lower rate but accepts potential loss or modification of services.
Given a particular communications scenario, it would be useful either at service creation or at service run-time to be able to determine (as described above) which components of a service, if any, are involved in an interaction and even more useful to determine the smallest subset of features actually responsible for the interaction. This subset of features can be stored as an inference about the features involved, so that subsequent attempts to use these features together need not rediscover, by recomputing from scratch, that this set of features leads to interaction. Instead, this information can be stored as an inferred xe2x80x9cno-goodxe2x80x9d, which can save a great deal of effort in a similar situation in the future. This information could also be fed back into the feature design phase, where it could be used to create features without this particular interaction.
Conversely, knowing which subsets of components, from all features provided, can be used together without causing an interaction, would also be useful. Precompiling this information into tables and then simply performing a lookup could be useful to bypass the potentially time consuming search task.
Ridding the system of the ability to interact entirely, by removing all features which could possibly interact at all or limiting their functionality, might result in a network too inflexible to be practical. For example, since it is known that CW and CFB do not work together, one solution would be to simply remove one of them from the system. However, it is possible that a customer might favour CW in some cases and CFB in other cases. Having removed a feature from the system, or reduced its functionality, no longer gives the customer the option. In more complex scenarios, these preferences might not just be single features, but could consist of sets of features.
A constraint satisfaction problem (CSP) in general consists of a set of variables, a set of values which can be assigned to each variable, and a set of constraints which describe the valid sets of assignments of values to variables. A solution to a constraint satisfaction problem is an assignment of a value to each variable that satisfies all of the constraints. Problems can be represented as graphs, where each variable is represented by a node, each value as a node""s possible labels, and each constraint by a line, or lines, connecting the variables constrained.
For the purposes of embodiments of the present specification, a constraint satisfaction problem based on one or more feature representations could be expressed as a data set defining call processing in provision of communications services, the data set comprising:
i) an identifier for each of a set of variables, the set of variables comprising at least a service feature status, an equipment status and a call processing variable,
ii) a set of values associated with each of the set of variables, which values can be instantiated in provision of a service or feature, and
iii) a set of constraints which define, for instance by listing, combinations of values between different variables to be instantiated at the same time in provision of a service or feature.
Inconsistency in a constraint satisfaction problem is then identified by any two or more constraints which are incompatible in that they define respective combinations which specify a different value for the same variable. A solution of an inconsistency may then be the selection of a new value for a variable, usually together with at least one new constraint which applies to the new value and defines a combination which excludes the inconsistency.
In embodiments of the present invention, a constraint satisfaction problem is generated for a potential service feature together with at least one other service feature and the problem is reviewed to identify one or more inconsistencies. If one or more inconsistencies are identified, the data set represented by the problem is modified, for instance by changing a value and/or constraint, so as to eradicate one or more of the inconsistencies. The modified data set can then be used in the provision of improved communications services.
Due to the dynamic nature of the feature interaction problem, and most telecommunications problems in general, the basic CSP model is insufficient. What is required is a representation capable of modelling the changes that occur, such as when a communications session is initiated. As a result, a form of dynamic CSP representation is needed.